Gestion des incidents à l'ère de DevOps

Appliquez les principes d'une communication ouverte et sans reproches aux équipes de gestion des incidents

Vous ne pouvez pas repenser la façon dont vous développez, déployez et utilisez des logiciels sans repenser votre réponse aux incidents.

Dans leur discussion phare de 2009, « 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr » (Plus de 10 déploiements par jour : la coopération entre les équipes de développement et opérationnelles chez Flickr), John Allspaw et Paul Hammond ont esquissé une vision d'un monde dans lequel les développeurs et les équipes informatiques opérationnelles collaborent et livrent régulièrement. Au cours de la décennie qui a suivi, cette vision s'est concrétisée en tant que mouvement DevOps.

Par nature, DevOps s’appuie sur de nouvelles méthodes de réponse aux incidents. Ce n’est pas surprenant que la gestion des incidents ait reçu autant d’attention dans le discours de John Allspaw et Paul Hammond. Paul Hammond explique : « Il est important de comprendre que des échecs vont se produire. La question n’est pas de savoir s’ils surviendront, mais quand. »

Contrairement aux frameworks comme ITIL, il n'existe pas de document dit officiel reprenant les bonnes pratiques pour une équipe DevOps. Mais nous pouvons généralement convenir que, au fond, DevOps vise à apporter une valeur business à une organisation en éliminant les silos organisationnels, en augmentant la transparence et en favorisant une communication ouverte entre les développeurs et les équipes des opérations informatiques.

Cette même culture de la transparence, de la visibilité et de l'apprentissage rapide s'étend à la gestion des incidents.

Pourquoi ? Parce que les premières étapes de la gestion des incidents (qui sont aussi les plus critiques) consistent à comprendre ce qui a posé problème, à charger les bonnes personnes de résoudre le problème et à favoriser une culture sans reproches. 

La gestion des incidents DevOps requiert une culture de communication ouverte et sans reproches entre les développeurs et les équipes informatiques opérationnelles. Elle nécessite également d'établir des processus légers qui améliorent la fiabilité des services informatiques, augmentent la satisfaction client et accroissent la valeur métier. Un ingénieur DevOps peut aider à implémenter la culture et les pratiques DevOps. 

En comparaison, ITIL est un ensemble prescrit de 26 processus, procédures, tâches et checklists conçus pour améliorer des pratiques spécifiques dans la gestion des services informatiques. Le framework se concentre sur la qualité et la cohérence des services et sur la création de systèmes plus résilients.

L'un des avantages d'ITIL ? Les organisations qui souhaitent améliorer l'ITSM peuvent s'appuyer sur des bonnes pratiques sous forme de modèle au lieu de partir de zéro. Bien que certaines personnes pensent qu'ITIL est plus adapté aux grandes entreprises, le framework est si flexible que les petites entreprises peuvent choisir les processus qui leur sont utiles et y trouver de la valeur.

ITIL a cependant un inconvénient : si vous êtes pressé de modifier votre processus de réponse aux incidents, le framework peut impliquer une gestion formelle des changements et un consultant expert, ce qui retarde les améliorations.

Pour les équipes qui souhaitent se lancer immédiatement, l'approche DevOps de gestion des incidents les aidera à se rassembler et à profiter immédiatement des avantages.

Processus de gestion des incidents DevOps

L'approche DevOps de gestion des incidents ne diffère pas radicalement des étapes traditionnelles d'une gestion efficace des incidents. La gestion des incidents DevOps met explicitement l'accent sur la participation des équipes de développement dès le début (y compris les équipes d'astreinte) et sur l'assignation du travail en fonction de l'expertise, et non des intitulés de poste.

1. Détection

Au lieu d'espérer (inutilement) qu'aucun incident ne survienne, les équipes de réponse aux incidents DevOps accordent une grande importance à la préparation. Elles travaillent en collaboration pour planifier leurs réponses en cas d'incidents en identifiant les faiblesses des systèmes. Elles mettent en place des outils de surveillance, des systèmes d'alerte et des runbooks qui aident chaque membre à savoir qui contacter lorsqu'un incident est détecté et la marche à suivre.

2. Réponse

Plutôt que d'avoir un seul ingénieur d'astreinte responsable de la réponse à tous les incidents dans une équipe d'astreinte, les équipes de gestion des incidents DevOps désignent plusieurs de leurs membres à contacter lors des remontées. Si l'ingénieur d'astreinte désigné ne peut pas résoudre un incident seul, il peut se servir d'un runbook comme guide. Il peut faire appel aux bonnes personnes pour évaluer l'impact et le niveau de gravité du problème et le faire remonter aux bons intervenants.

3. Résolution

Lorsque le moment est venu de répondre à un incident, les équipes de gestion des incidents DevOps parviennent souvent à une résolution rapide. En effet, à l'échelle globale, ce sont elles qui connaissent le mieux le code de l'application ou du système, puisqu'elles l'ont écrit. Et, grâce à une préparation approfondie et à de bons systèmes de communication, elles peuvent résoudre ensemble l'incident, et ce, plus rapidement qu'une équipe de réponse tierce découvrant le code pour la première fois.

4. Analyse

Les équipes de gestion des incidents DevOps clôturent un incident grâce à un processus de post-mortem sans reproches. Elles se réunissent pour partager des informations, des métriques et des enseignements dans le but d'améliorer continuellement la résilience de leurs systèmes et de résoudre rapidement et efficacement les incidents futurs.

5. Préparation

Une fois qu'un incident est résolu, que toutes les étapes de remédiation ont été finalisées et que le système a été restauré, les équipes de gestion des incidents DevOps prennent du recul pour évaluer leur niveau de préparation au prochain incident. Grâce aux enseignements tirés de leur processus de post-mortem, elles actualisent leurs runbooks et opèrent les ajustements nécessaires pour surveiller les outils et les systèmes d'alerte. Dans l'univers DevOps, l'accent mis sur l'amélioration continue s'applique au personnel et à l'équipe, pas seulement à la technologie. Après un incident, chaque membre de l'équipe est mieux préparé pour le prochain.

Bonnes pratiques pour des équipes DevOps de gestion des incidents efficaces

L'adoption d'une approche DevOps pour la réponse aux incidents peut conduire à une meilleure communication entre les équipes de développement et informatiques opérationnelles, à une réponse aux incidents et à une remédiation plus rapides, ainsi qu'à un système plus résilient.

Automatiser les processus et les workflows

Intégrez vos outils de centre de services, de surveillance, de gestion des tickets, de CMDB/de gestion des actifs et de chat pour simplifier les alertes d'incidents informatiques et les workflows afin de garantir que les bonnes personnes reçoivent les informations nécessaires pour démarrer une résolution. Configurez des runbooks grâce à des workflows prédéfinis afin que les utilisateurs puissent se mettre rapidement au travail en cas d'incident.

Communiquer entre équipes

Assurez-vous que les membres de vos équipes peuvent communiquer au sein de l'organisation grâce à des outils de chat en temps réel. Utilisez des outils qui créent un enregistrement de l'incident afin que tout le monde puisse intervenir à tout moment et se tenir informé de ce qui s'est passé et de ce qui doit être fait.

Adopter l'approche sans reproches

Une fois l'incident résolu, rassemblez-vous en équipe pour examiner ce qui s'est passé lors d'une session de post-mortem sans reproches. Évitez de pointer du doigt et concentrez-vous sur le partage d'informations qui aident chacun à mieux faire son travail et qui contribuent à créer un système plus fiable.

Identifier et se concentrer sur les résultats financiers de l'entreprise

La réponse aux incidents DevOps est plus qu'un moyen pour améliorer la communication. En effet, il s'agit là d'assurer la collaboration entre les équipes développement et opérationnelle pour offrir une réelle valeur métier. Suivez les métriques telles que le temps moyen de détection (MTTD), le temps moyen jusqu'à la réparation (MTTR) et le temps moyen entre pannes (MTBF) pour comprendre la vitesse d'amélioration de votre équipe.

Utiliser la planification d'astreinte pour positionner les développeurs et les administrateurs système en tant que SRE

Dans les équipes DevOps, la frontière entre développeur et administrateur système commence à s'estomper et ceux qui répondent à l'incident deviennent souvent des ingénieurs chargés de la fiabilité du site (SRE). Néanmoins, les membres de l'équipe auront probablement des connaissances spécialisées soit dans le code applicatif, soit dans le code infrastructurel. Configurez votre planning d'astreinte pour vous assurer que vous disposez des bons experts pour répondre aux incidents.

Découvrez comment Jira Service Management peut appuyer une approche DevOps de gestion des incidents.